In my post about Batteries and Pyro Circuits, one of my suggestions was to remove the protection circuit board from LiPo cells used with Altus Metrum flight computers. To help out folks who want to do this themselves, I put together and posted a how-to with photos in the Documents section of our web site.

Keith and I have discovered a change in the behavior of the protection circuits integrated in the LiPo batteries we sell for use with Altus Metrum products that poses a risk for our customers. This post is meant to document what we now know, communicate changes we're planning as a result, and explain what we think flyers of our existing electronics and batteries may want to do to maximize their chances of successful flights. Background Choosing batteries and designing pyro circuits for high power rocketry avionics involves a variety of trade-offs. Reliability is the highest concern, both because nobody wants to lose an airframe due to a failed pyro event, and also because airframes recovering anomalously have safety implications. But we also care about other factors including cost and weight, and usually want to minimize the complexity of both the electronics and the overall installation. The objective of a pyro circuit is to dump enough energy rapidly into an electric match to cause it to catch fire. We need batteries both to power the electronics that decide when to fire the charge, and to provide the energy that actually ignites the match. The two most common battery types seen in the rocketry hobby are alkaline cells, often the nominal 9V rectangular variety, and rechargeable batteries based on Lithium Polymer (LiPo) chemistry. LiPo cells are 3.7 volts per cell nominal voltage, are very light, and have a high energy density. LiPo capacity is measured in units of current times time, so an 850mAh cell should be able to deliver 850 milliamps for an hour. The battery industry also uses something called a "C rate" to describe how fast the battery can be usefully discharged, wich is a multiplier relative to the battery capacity. So a battery with 850mAh capacity and a "2C" rating can deliver current at a sustained rate of 1700mA until discharged, while the same capacity at a "5C" rating can deliver 4250mA. By comparison, most 9V alkaline batteries are actually composed of 6 individual 1.5V cells enclosed in a wrapper. It's hard to get hard numbers for capacity and discharge rate, since in an alkaline cell the two are not independent, and the discharge rate is related to the volume of each individual cell. The data sheet for an Energizer 522 shows just over 600mAh at a 25mA discharge rate, dropping to about 300mAh at a 500mA discharge rate. Importantly for use in pyro circuits, LiPo cells have a very low source impedance, which means they can source immense amounts of current. It's not unusual for cells in the 1000mAh range to have ratings in excess of 30C! Because this rapid discharge ability can pose a risk of fire, it's common for LiPo cells to come with a "protection board" integrated into the battery assembly that is designed to limit the current to some rate such as 2C continuous duty. In large airframes, or projects that involve staging, air-starts, or other complex pyro event sequences, the most reliable approach will always be to use separate batteries for the control electronics and the source of pyro firing power. In the limit, having separate pyro batteries for each pyro charge with the control electronics only providing the switching to connect the batteries to the charges could even make sense. But for most airframes, this is overkill, and the increases in mass, volume, and wiring complexity just don't make sense. The challenge, then, is how to design electronics that will robustly initiate pyro events without negatively affecting the rest of the electronics when operating from a single shared battery. Altus Metrum Pyro Circuits The very first prototypes of TeleMetrum were designed to use a single-cell LiPo battery, and had an on-board 100mA charging circuit. Because we needed 5 volts to power the accelerometer, we had a small switching regulator that up-converted the LiPo voltage, and we used some of that regulator's output to charge a 1000uF capacitor. The pyro circuit used Fairchild FDN335N N-channel MOSFET switches in a low-side switching configuration to dump the energy stored in the capacitor through an attached ematch. Those FETs had an on resistance of under a tenth of an ohm in our operating conditions. The circuit worked very reliably, but the 1000uF electrolytic cap was huge and we struggled with the mechanics of such a large part hanging off the board... It turns out that 3.7 volts is way more than enough to fire a typical low-current e-match or equivalents like the Quest Q2G2 igniters. In fact, bench testing with a good digital oscilloscope showed that a typical e-match with resistance of 1.3-1.8 ohms will fire in approximately 13 microseconds when hit with the nominal 3.7 volts from a LiPo. So, starting with our v0.2 boards, we switched to using the LiPo battery voltage directly to fire the pyro charges, eliminating the clunky electrolytic capacitor entirely. We also switched to the Fairchild FDS9926A dual N-channel MOSFET whose specs are better in all regards for our application. The on resistance is down around 40 milli-ohms in our circuit, such that the current ratings are much higher (FET current limits are primarily driven by how much heat is generated due to current flowing through the channel's on resistance). Because using the LiPo voltage directly means we're effectively temporarily putting a very low resistance across the battery during the pyro events, the input voltage to the voltage regulator gets pulled down. To ensure the processor could "ride through" these events, we added a 100uF surface mount bulk capacitor on the 3.3 volt regulated voltage rail, which bench testing demonstrated was more than sufficient to maintain processor operation through pyro events. And that is essentially the same pyro circuit on all the boards, both TeleMetrum and TeleMini, that we have shipped to date. What's Changed The LiPo batteries we source and sell with our electronics come with a protection board and cable terminated in a 2-pin, 2mm "JST" connector. The specs on the protection board have always been "2C continuous", but we observed the ability to source much higher currents for short periods such as the 13 micro-seconds or so required to fire an e-match. Thus these protection circuits seemed just fine .. we could fire e-matches with a burst of current but were protected against short circuits in the wiring or our boards by the 2C continuous limit. Unfortunately, the most recent batch of batteries we sourced seem to have a much "twitchier" protection circuit. We can draw more than 2C for short bursts, but not as much as with prior boards, and not for as long an interval. With a 1 ohm power resistor on the pyro terminals of one of our boards, we get about 9 milliseconds of power before the protection circuit cuts in and shuts the battery down. The power stays down until all load is removed, which at least means the board is turned off and back on again, and in some cases could even mean the battery is unplugged and re-plugged since we draw trace current to keep the GPS memory alive even when the power is turned off, and at least some of the new batteries see that as enough to keep the power turned off after an over-current event. For many e-matches, this isn't an issue, since 9 milliseconds is way longer than the 13 microseconds needed to fire the charge. Unfortunately, we've discovered that many of the e-matches bought and used in the rocketry hobby are actually made for use in the fireworks industry, where it is desireable to retain continuity after firing so that series connections of e-matches all can fire even if some fire faster than others! This means that while the resistance goes up some after firing, sometimes the drain on the battery remains sufficient to cause the protection circuit to kick in even after the pyro charge has fired. What We're Doing About It If we remove the protection circuit from the LiPo (or jumper around it), all existing Altus Metrum products will operate successfully with pyro charges thave have an effective resistance of as low as 1 ohm. That's lower than any e-match or Q2G2 we've ever seen, so in effect what this means is that if you have an existing Altus Metrum flight computer, and you remove the LiPo protection circuit, you're good to go. This does not really make things any more "dangerous", since our battery chargers are all current limited and our discharge patterns will never cause heating of the battery. Frankly, in a rocket, the most likely way to cause a problem with a LiPo is by smashing or puncturing the actual battery during bench work or during a crash... and those cause the same problems with or without a protection board present. In the future, we will ship batteries that have either a much higher C rating on the protection circuit, or have no protection circuit at all. The number of problems reported by actual customers that we think should be attributed to LiPo protection circuit boards is very low, and we suspect most of our customers who are happily flying their boards can continue to do so. Ground testing where you fire pyro charges (or at least e-matches) using RF to issue the commands (not USB, since the LiPo charger is running any time USB is connected!) will confirm whether there's a problem. If the board resets (does startup beeps) after a pyro event, or shuts down completely (no LED activity), then you have a problem. If the matches light and the board keeps running, you're good to go. However, any Altus Metrum customer with LiPo batteries sourced from us or our distributors who is worried about this problem (even if you haven't seen problems in ground testing or previous flights), and who doesn't want to try soldering on the battery circuit board yourself, is welcome to contact us about removing the protection circuit for you. We won't charge anything other than shipping. To take advantage of this offer, just send email to fixmybattery@altusmetrum.org telling us how many of which capacity batteries you have that you'd like updated, and we'll respond with an RMA number and shipping details. Going Even Further As previously indicated, with the LiPo protection circuits removed, all of our current products will work reliably with at least 1 ohm across the pyro terminals. That should cover all real-world flying conditions just fine, but we're not satisfied yet. We've designed a new pyro control circuit that transfers the maximum possible energy to the load regardless of battery voltage without ever allowing the voltage to the processor to droop at all. We're testing this new circuit in various prototypes now, and if it pans out it will probably show up first in MegaMetrum and then trickle down to TeleMetrum and TeleMini as those products are updated later this year. The new pyro circuit tolerates 0 ohms (dead shorts) on the pyro terminals for as long as the battery can provide current, which is as good as it gets. We think the circuit is clever enough that we'll probably write more about it once we're finished validating it.

I bought some HTPC a few years ago to run XBMC, a neat media center solution. At the time, to avoid any problems, I installed it on top of a minimal Ubuntu Lucid installation with the official packages from the team XBMC. Recently, XBMC Eden has been released and XBMC has landed into Debian unstable. It was a good occasion to make the switch. TL;DR: Installing XBMC on Debian Wheezy is quite easy: it almost works out of the box. The big difficulty is the configuration of the remote control: either it works as you expect or you will have to scratch your head over the pile of layers needed to work with a remote control. The configuration of my HTPC is as follows:

• an Antec Micro Fusion 350 housing featuring a SoundGraph iMON IR receiver and LCD screen¹,
• a Zotac ION-ITX-D-E motherboard with an Intel Atom 330 CPU and an nVidia ION chipset,
• some Onkyo AV receiver connected through HDMI,
• a Logitech Harmony 555 as remote control.

Installation

Installing Debian Wheezy Installing Debian Wheezy² is pretty easy. Nowadays, getting a bootable USB key from a netinst image of Debian Installer for Wheezy is simplified:

$ sudo dd if=debian-testing-i386-netinst.iso \
>         of=/dev/disk/by-id/usb...

The installation was smooth with the exception of GRUB which was unable to install itself on the disk. This is a known bug when dealing with LVM and it comes with a simple workaround. I hope it will be corrected in time for Wheezy release. While this has little to do with the installation of XBMC, I wanted to test systemd which may become the default init in Debian (at least in Debian GNU/Linux). From README.Debian:

systemd can be installed alongside sysvinit and will not change the behaviour of the system out of the box. This is intentional. To test systemd, add init=/bin/systemd to the kernel command line and then rebooting, or install the systemd-sysv package.

The final system boots in about 15 seconds.

Configuring X Because video decoding in nouveau driver is still a work in progress, the use of the proprietary NVIDIA drivers is mandatory to be able to watch high resolution videos. Therefore, /etc/apt/sources.list should be completed with contrib and non-free repository. Then, you can install the appropriate packages: xserver-xorg-video-nvidia, nvidia-vdpau-driver and xserver-xorg. Here is my /etc/X11/xorg.conf.d/nvidia.conf:

Section "Device"
    Identifier     "NVidia ION"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    Option         "HWCursor" "False"
    Option         "NoFlip" "False"
    Option         "FlatPanelProperties" "Scaling = Native"
    Option         "DynamicTwinView" "False"
    Option         "ConnectedMonitor" "DFP-1"
    Option         "CustomEDID" "DFP-1:/etc/X11/edid.bin"
    Option         "NoLogo" "True"
EndSection
Section "Extensions"
    Option "Composite" "false"
EndSection

The CustomEDID option allows the driver to get an appropriate EDID even when the AV receiver is off. You can get yours, free of charge, with get-edid from read-edid package.

Installing XBMC Thanks to the work of Andr s Mej a, XBMC is now available in Debian Wheezy. To install it, just type aptitude install xbmc. I have dropped the following xbmc.service in /etc/systemd/system directory:

[Unit]
Description = XBMC media center
After = syslog.target
[Service]
User = xbmc
Group = xbmc
Type = simple
ExecStart = /usr/bin/xinit /usr/bin/xbmc-standalone -- :0
Restart = on-failure
[Install]
WantedBy = multi-user.target

Enable this service on boot with systemctl enable xbmc.service. You need to allow xbmc user to run X. The simplest way is to run dpkg-reconfigure -plow x11-common and to allow anybody to run X. sudo may be an alternative.

Configuration

Sound While I wanted to use PulseAudio, I want the AV receiver to be able to upmix stereo streams itself. With PulseAudio, it would always receive a 6-channel signal. Therefore, I directly use ALSA. First, unmute the appropriate outputs:

$ amixer scontrols   grep IEC958
Simple mixer control 'IEC958',0
Simple mixer control 'IEC958 Default PCM',0
Simple mixer control 'IEC958',1
$ amixer sset 'IEC958',0 unmute
$ amixer sset 'IEC958 Default PCM',0 unmute
$ amixer sset 'IEC958',1 unmute
$ sudo systemctl stop alsa-utils.service

The order of channels is incorrect. With the following /etc/asound.conf, we declare a new output, hdmi2, with a different mapping:

pcm.hdmi2  
  type asym
  playback.pcm  
    type plug
    slave.pcm "remap-surround51"
   
 
pcm.!remap-surround51  
  type route
  slave.pcm "hdmi"
  ttable  
    0.0= 1
    1.1= 1
    2.4= 1
    3.5= 1
    4.2= 1
    5.3= 1
   
 

In XBMC, this output should be used instead of the default one. hdmi should still be used for passthrough. To check if each speaker is mapped correctly, one can use speaker-test -D hdmi2 -c 6.

LCD display The LCD display integrated into the SoundGraph iMON is supported by the imon kernel module and the lcdproc package. I have only modified a few lines of /etc/LCDd.conf to make it work:

[server]
Driver=imonlcd
ServerScreen=off
[imonlcd]
Protocol=1
OnExit=2
Contrast=400

Remote control This is the most difficult part. I have a Logitech Harmony remote which is a great universal remote. Its support in Linux is acceptable: you can configure through Logitech website and use congruity to push the new configuration.

Remote controls and Linux Before Linux 2.6.36, most remote controls would need LIRC to work:

• The driver receives the signal from the IR receiver and make it available through /dev/lirc.
• lircd, with the help of a configuration file describing the protocol used by the remote control, will read the signal and turn it into the appropriate LIRC code.
• XBMC connects to lircd and receives incoming LIRC codes. It will translate them to an XBMC command. This translation is specified in Lircmap.xml.
• XBMC maps each command to an action (like Play, Fullscreen, ) using a keymap. This keymap can handle commands received by a remote control, but also by a keyboard, a mouse or a joystick.

Since Linux 2.6.36, remote controls will be mapped as a generic input device (just like a keyboard):

• The driver receives the signal from the IR receiver.
• The signal will be handled by a decoder. The configuration of this decoder is done in userland by ir-keytable. The decoder will turn the signal into the appropriate event (usually, some keypress).
• X will listen to those events and turn them into X key events.
• XBMC will receive them and use the appropriate keymap to turn them into actions.

And to add more complexity to the mix, in this last case, you can still use LIRC: lircd will listen to events generated by the kernel and turn them into LIRC codes. This can be very confusing. Moreover, the SoundGraph iMON IR receiver accepts two IR protocols: the iMON protocol and the RC-6 one. The Linux driver accepts both of them but uses the first one by default. The RC-6 protocol is the protocol used by many MCE remote controls. I hope you are still with me here.

The easy way To get a reasonable configuration out of the box, here is how to configure each layer:

Logitech Harmony remote

Configure it as a Microsoft branded Media Center PC: Windows Media Center SE.

iMON IR receiver

It must use RC-6 protocol. See below for more details.

LIRC

In /etc/lirc/hardware.conf, put DEVICE=/dev/input/by-id/usb-15c2_0038-event-if00 and DRIVER=devinput. In /etc/lirc/lircd.conf, just put include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput".

XBMC

With the previous bits done, it should just work out of the box.

To switch to RC-6 protocol, install the ir-keytable package and use the following commands:

$ sudo modprobe rc-imon-mce
$ sudo ir-keytable -s rc0 -p rc-6 -c -w /lib/udev/rc_keymaps/imon_mce
Read imon_mce table
Old keytable cleared
Wrote 77 keycode(s) to driver
Protocols changed to RC-6

To make the change permanent, add the rc-imon-mce module to /etc/modules and create /etc/udev/rules.d/90-imon.rules with the following content:

# Override the keytable for iMON
ACTION=="add change", SUBSYSTEM=="rc", DRV_NAME="imon", \
   RUN+="/usr/bin/ir-keytable -s $name -p rc-6 -c -w /lib/udev/rc_keymaps/imon_mce"

The hard way Now, you may want to bind custom actions to some (physical or virtual) buttons. Basically, you are left with two solutions:

1. Start from the basic configuration with LIRC and add more buttons at each levels (there are five of them!).
2. Remove LIRC and start with the Logitech Harmony acting as a Microsoft MCE keyboard.

The first option can be quite difficult. You need to find an unused code for the Logitech Harmony. You can try to make it learn a new code if you have some RC-6 remote control. Then, you need to ensure that this code will be present in the keytable used by ir-keytable. If not, you need to add it. That s not easy since you need a to enable some debug stuff in the kernel to find the appropriate scancode. After that, the code needs to be translated in lircd.conf. You will then have to translate it again in Lircmap.xml. At least, you need to add it to a keymap in XBMC. The other way is not ideal but seems less cumbersome. The first step is to configure the Logitech Harmony as a Microsoft MCE keyboard: it has a lot of available keys. Because of the lack of multimedia keys, let s match the keyboard configuration of XBMC:

Button	Command	Button	Command
Channel Down	PageDown	Stop	X
Channel Up	PageUp	Skip back	Comma
Prev	Backspace	Skip forward	.
Up	DirectionUp	Play	P
Down	DirectionDown	Rewind	R
Left	DirectionLeft	Fast forward	F
Right	DirectionRight	Star	Delete
OK	Enter	Pound	W
Menu	C	Red	F1
Exit	Esc	Green	F2
Guide	Tab	Yellow	F3
Info	I	Blue	F4

Unfortunately, the keytables provided with ir-keytable are not complete enough. I have built a more complete table³. With this table and the bindings described above, most functions will work out of the box without LIRC. Additional keys can be configured in a dedicated keymap⁴. Here is an excerpt of mine:

<keymap>
 <global>
  <keyboard>
    <end>XBMC.ShutDown()</end>
    <f1>XBMC.ActivateWindow(MusicLibrary)</f1>
    <f2>XBMC.ActivateWindow(Videos,TvShowTitles)</f2>
    <f3>XBMC.ActivateWindow(Videos,MovieTitles)</f3>
    <f4>XBMC.ActivateWindow(Weather)</f4>
  </keyboard>
 </global>
 <FullscreenVideo>
  <keyboard>
   <opensquarebracket>SubtitleDelayMinus</opensquarebracket>
   <closesquarebracket>SubtitleDelayPlus</closesquarebracket>
   <f6>xbmc.runscript(script.xbmc.subtitles)</f6>
  </keyboard>
 </FullscreenVideo>
</keymap>

FTP Instead of using SSH, I prefer to drop new files with anonymous FTP. vsftpd fits this purpose. Here is my configuration file:

listen=YES
xferlog_enable=YES
use_localtime=YES
setproctitle_enable=YES
secure_chroot_dir=/var/run/vsftpd/empty
nopriv_user=ftp
ftpd_banner=XBMC
hide_ids=YES
ftp_username=xbmc
anon_umask=022
anon_root=/home/xbmc/media
anonymous_enable=YES
write_enable=YES
anon_upload_enable=YES
anon_world_readable_only=YES

It is currently not compatible with systemd (see bug #670308). I have removed the symlink in /etc/rc2.d and I have used the following unit file:

[Unit]
Description=Vsftpd ftp daemon
After=syslog.target network.target
[Service]
Type=simple
ExecStart=/usr/sbin/vsftpd /etc/vsftpd.conf
ExecReload=/bin/kill -HUP $MAINPID
ExecStartPre=-/bin/mkdir -p /var/run/vsftpd/empty
[Install]
WantedBy=multi-user.target

Miscellaneous

1. In /etc/default/grub, reduce TIMEOUT to 0 to shorten the boot time.
2. Enabling dirty regions can help speed up XBMC.
3. aptitude install upower pm-utils to be able to shutdown/suspend from XBMC. Since XBMC was configured to be started outside any session, you need to explicitely give the appropriate rights by creating the following /var/lib/polkit-1/localauthority/50-local.d/xbmc.pkla:

   [Actions for xbmc user]
   Identity=unix-user:xbmc
   Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*
   ResultAny=yes
   ResultInactive=yes
   ResultActive=yes
   

---

1. The readibility of the LCD screen is very bad. You should look at the VFD version. The IR receiver reception is poor. The provided remote control is a joke.
2. Debian Wheezy is not yet released. If you are unfamiliar with Debian, it may be cumbersome to maintain it until the freeze happens in a few months.
3. Some keys are missing from the provided table. For example, there is no exclamation mark. While there is a scan code for such a key in RC-6 protocol, there is no appropriate key code to translate to: on a QWERTY keyboard, the exclamation mark is on the same key as the number 1. It is possible to map it to some other key code, but the mapping would have been difficult to use.
4. For example, in ~/.xbmc/userdata/keymaps/harmony.xml.

Does anyone use fstrim on an XFS formatted SSD partition? I ve got two systems with XFS root partitions that fstrim seems to do (almost) nothing on, but it seems to work correctly on another system with formatted with ext4.

Details follow: System 1 is an AMD 1090T with a Patriot Torqx 2 128GB SSD. System 2 is also an AMD 1090T with a Patriot Pyro 120GB SSD. I ve been running both for several months without any TRIM support because I (incorrectly) assumed that XFS support for TRIM was automatically enabled. I ve recently discovered that it s not, and also that it s better performance-wise to run fstrim regularly from cron for batch-mode TRIM operations. Anyway, System 1 takes over 7 minutes to run fstrim, and claims to have trimmed about 16GB .but if i run it again it still takes over 7 minutes and claims to have trimmed about the same amount of data (slightly less).

# time fstrim -v /
/: 16777764864 bytes were trimmed
real 7m31.089s user 0m0.004s sys 0m9.705s
# time fstrim -v /
/: 16772276224 bytes were trimmed
real 7m8.973s user 0m0.000s sys 0m9.165s

System 2 takes over 28 minutes to run fstrim and claims to trim about 51GB of data (it s had an SSD for a lot longer than System 1. It also has /home on /, whereas System 1 has /home on a separate disk). Similarly, running it again immediately afterwards also takes about the same amount of time and claims to trim about the same amount of data.

# time fstrim -v /
/: 51594948608 bytes were trimmed
real 28m19.832s user 0m0.000s sys 0m6.264s
# time fstrim -v /
/: 51499814912 bytes were trimmed
real 28m29.230s user 0m0.000s sys 0m6.328s

(interestingly, the Pyro is a *much* faster SSD than the Torqx2. it s SATA3 and is capable of about 500-550MB/s. The Torqx 2 is SATA 2 and is capable of about 230MB/s seems as if TRIM speed is roughly the
same for both drives, proportional to the amount of data to be trimmed. almost certainly limited by the flash speed with the internal controller differences being negligible for this task) OK, so it seems as if fstrim claims X bytes were trimmed, but it doesn t actually happen. On a third system, I have / on an SSD formatted with ext4. System 3 is an Intel Xeon E5607, and the SSD is an OCZ AGILITY3 120GB.

# time fstrim -v /
/: 14267424768 bytes were trimmed
real 2m25.222s user 0m0.000s sys 0m0.636s
# time fstrim -v /
/: 0 bytes were trimmed
real 0m0.001s user 0m0.000s sys 0m0.000s

on ext4 fstrim seems to work as expected. The OCZ SSD is also a LOT faster than the Patriot SSDs (roughly 14GB trimmed in 2.5 minutes). anyone seen this before? is it a bug in XFS SSD handling? or am i just misinterpreting the results? my google-fu can t find anyone with similar problems, just mailing list articles and an XFS wiki page saying that it works, and that running fstrim regularly is recommended over using the discard mount time option. fstrim and XFS is a post from: Errata

We've had sporadic Altus Metrum customer reports about RF susceptibility issues with their TeleMetrum installations. In almost every case, these problems have been completely resolved by either making sure the system battery has sufficient charge before launch, or through the application of standard engineering techniques such as twisting wire pairs to reduce differential coupling. However, even when every technique we could think of had been applied, once in a while someone still had issues. Around the time of LDRS this year, the incidence of such reports seemed to increase. One customer, in particular, had an installation in which he virtually always saw continuous resets of the board once his 54mm airframe was put on a launch rail, and several customers reported seeing board resets during ejection charge firing. Keith and I saw a board reset during main charge firing happen in person at NCR's Oktoberfest, and with a couple days available to work together after that launch, we decided it was time to figure out what was really going on. Here's what we've learned. In bench testing, it quickly became clear that the problem was the 3.3 volt power supply rail getting pulled down far enough to reset the CPU. This most frequently happened during ejection charge firing, when the input of the LDO regulator is pulled down by the near-short presented by the e-match when a pyro FET is turned on. To keep the 3.3 volt rail voltage up during firing, we include a 100uF bulk capacitor on the regulator's output. In all of our prior bench testing, we never saw the 3.3 volt rail droop significantly. Clearly something had changed... or maybe several things had changed? The first thing I wondered about was whether the new Kalman filtering code, which requires more compute cycles from the processor, might be consuming enough more power to pull the rail down faster during charge firing. After poking around at it, though, we have no data to suggest the new code makes a measurable difference in power consumption. The next thing we pondered was that at least some of the e-matches we and others are using in the hobby now come from the fireworks industry, where it is apparently considered a feature for the match to retain continuity after firing. This means the input of the LDO gets held down for longer than with the e-matches we used to use and Quest Q2G2 igniters that open when fired. But that still didn't make sense as the root cause, as we chose the FET firing time such that even with a dead short across the igniter terminals, the 3.3 volt rail wouldn't be pulled down far enough to cause trouble during firing. One of the big changes between v1.0 and v1.1 on TeleMetrum was that the newer boards incorporate a better reset circuit. This helps ensure the GPS chip always comes up running at power on, which was a problem at temperature extremes with older boards. However, a side-effect of this change is that a v1.1 board will reset any time the 3.3 volt rail drops below 3.15 volts, whereas older boards didn't trip until a much lower voltage. So the recent increase in reports might just be related to more v1.1 boards being placed in service? While experimenting on the bench, we observed that injecting RF energy into the input of the LDO regulator had the effect of pulling down the output voltage, presumably because the internal reference source accumulates charge and is fooled into thinking the output is too high. Since our designs all have the power switch contacts ahead of the LDO, the wires going out to the switch and back are effectively an antenna... as are, to a lesser extent, the wires going to the e-matches. There is some variability from part to part in just how badly the LDO reacts. But by attaching a tuned length of wire as an antenna to the LDO input and playing around, we were finally able to reproduce the problem reliably on a test board at my bench! On further analysis, we realized that the output of the USB battery charger chip and the input of the LDO both expect a 1uF bypass cap to ground. At some point, those looked redundant and we eliminated one of the two. Unfortunately, we weren't internalizing the fact that the switch leads were between the two caps, and the one we left was on the output of the charger and not at the input of the LDO. Placing a suitable bypass cap right at the input of the LDO turns out to have a truly dramatic effect on RF immunity! Once we realized that RF getting into the LDO input was the problem, Keith pointed out that we used to see "noise" in the accelerometer data on earlier boards that was caused by the 3.3 volt rail moving slightly during radio transmit, which we fixed with a hardware change on v1.1. We are now convinced that this was at least partly related to RF coupling to the LDO input, not just the change in power consumption on the LDO output. We didn't realize what was going on in earlier testing because we often didn't have ematches wired up, so RF coupling was minimal. But going back to flights logged with v1.0 boards that included deployment, and studying the magnitude of the "steps" in acceleration data observed when the transmitter was on, Keith was able to compute the amount the 3.3 volt rail must have sagged if the real acceleration wasn't changing... which in some cases was as much as 180mV! We think this proves that RFI could cause the LDO to drop its output voltage below the reset controller set point on v1.1 boards. Based on these observations, I'm making two hardware changes for the next version of TeleMetrum (version 1.2), and Keith is also making a software change. We have tested all of these changes on real boards both on the bench and in test flights, and the net effect is a major improvement in the RF immunity of TeleMetrum. The first hardware change is moving to a slightly lower trip voltage on the reset controller. Instead of 3.15, the new part trips at 3.00 volts nominal. This gives us more "headroom" to tolerate 3.3 volt rail droop during charge firing, and will allow the board to operate longer on a given battery charge. This change is not relevant for v1.0 and prior. The second hardware change is adding an appropriate bypass capacitor right at the LDO input. This requires a PCB update, but it's possible for me to update existing production boards by adding an 0402 cap right across the appropriate pins on the regulator chip. The software change prevents our altimeters from turning on the radio transmitter while an ejection charge is firing. Since the RF transmitter draws substantial additional power, this should help keep the 3.3 volt rail from drooping. This may not really matter, but it feels like the right thing to do. This change will be part of our next stable firmware release. We think most TeleMetrum customers need not worry about these updates. But if you have seen odd resets on the rail or during ejection charge firing in flight with a TeleMetrum v1.1, feel free to contact me about updating your existing board to include these improvements.

After spotting an upload of mira, who in turn spotted an upload of abe (the package, not an upload by me aka abe@d.o), mira (mirabilos aka tg@d.o) noticed that there are Debian packages which have same name as some Debian Developers have as login name. Of course I noticed a long time ago that there is a Debian package with my login name abe . Another well-known Debian login and former package name is amaya. But since someone else came up with that thought, too, it was time for finding the definite answer to the question which are the DD login names which also exist as Debian package names. My first try was based on the list of trusted GnuPG keys:

$ apt-cache policy $(gpg --keyring /etc/apt/trusted.gpg --list-keys 2>/dev/null   \
                     grep @debian.org   \
        	     awk -F'[<@]' ' print $2 '   \
                     sort -u) 2>/dev/null   \
                   egrep -o '^[^ :]*'
alex
tor
ed
bam
ng

But this was not satisfying as my own name didn t show up and gpg also threw quite a lot of block reading errors (which is also the reason for redirecting STDERR). mira then had the idea of using the Ultimate Debian Database to answer this question more properly:

udd=> SELECT login, name FROM carnivore_login, carnivore_names
      WHERE carnivore_login.id=carnivore_names.id AND login IN
      (SELECT package AS login FROM packages, active_dds
       WHERE packages.package=active_dds.login UNION
       SELECT source AS name FROM sources, active_dds
       WHERE sources.source=active_dds.login)
      ORDER BY login;
 login                   name
-------+---------------------------------------
 abe     Axel Beckert
 alex    Alexander List
 alex    Alexander M. List  4402020774 9332554
 and     Andrea Veri
 ash     Albert Huang
 bam     Brian May
 ed      Ed Boraas
 ed      Ed G. Boraas [RSA Compatibility Key]
 ed      Ed G. Boraas [RSA]
 eric    Eric Dorland
 gq      Alexander GQ Gerasiov
 iml     Ian Maclaine-cross
 lunar   J r my Bobbio
 mako    Benjamin Hill
 mako    Benjamin Mako Hill
 mbr     Markus Braun
 mlt     Marcela Tiznado
 nas     Neil A. Schemenauer
 nas     Neil Schemenauer
 opal    Ola Lundkvist
 opal    Ola Lundqvist
 paco    Francisco Moya
 paul    Paul Slootman
 pino    Pino Toscano
 pyro    Brian Nelson
 stone   Fredrik Steen
(26 rows)

Interestingly tor (Tor Slettnes) is missing in this list, so it s not complete either At least I m quite sure that nobody maintains a package with his own login name as package name. :-) We also have no packages ending in -guest , so there s no chance that a package name matches an Alioth guest account either

I ve actually spent a few hours searching around for a good backup solution for my mailbox until I decided to stick with getmail. What you ll be able to achieve after reading this HowTo and deploying the following setup is:

1. A full backup of your e-mail DATA in the Mbox format. (yes, Gmail s labels / folders as well)
2. Prevent getmail to mark all mails as read after delivering them. (this was a pretty bad issue since getmail was marking all my mails as read even if I did not access my e-mail at all)
3. Keep your backups up-to-date with the latest content from your mailbox. (by default getmail grabs all the DATA from your mailbox and fills up the Mbox / Maildir content keeping deleted mails. So let s say I deleted a mail two days ago, well it ll still appear on today s backups. This behaviour is definitely unwanted)

I ll now move to explain a few details about my new configuration but before moving to tweak getmail s main config file, please do the following change on _retrieverbases.py* :

return self._getmsgpartbyid(msgid, (RFC822) ) to return self._getmsgpartbyid(msgid, (BODY.PEEK[]) )

When done grab the following getmailrc and adapt it to your needs**:

[retriever]
type = SimpleIMAPSSLRetriever ## or SimplePOP3SSLRetriever.
server = imap.gmail.com ## or pop.gmail.com for POP3.
username = example@gmail.com
password = password ## so-called Gmail s labels should be listed one by one here for getmail to retrieve mail from them successfully. mailboxes = ( INBOX , [Gmail]/Sent mail ,
ubuntu , gnome/example , linux/example ) [destination]
type = Mboxrd
path = ~/.getmail/backup.mbox [options]
delivered_to = false ## No delivered_to header added automatically.
received = false ## No received header added automatically.
verbose = 2 ## getmail will print messages about each of its actions.

When done we should go ahead setting up getmail s directories and config file:

mkdir $HOME/.getmail cp $HOME/getmailrc $HOME/.getmail/ ## Adapt $HOME/getmailrc to whatever dir you put that file into.

But pretty much all the remaining work will be done by a small shell script I wrote:

#!/bin/sh WORKDIR=$HOME/.getmail
date= date +%d-%m-%Y_%H:%M if [ ! -f $WORKDIR/backup.mbox ]
then
touch $WORKDIR/backup.mbox
fi getmail > $WORKDIR/getmail.log
OUT=$?
if [ $OUT -eq 0 ]
then
mkdir -p $WORKDIR/backups/ && mv $WORKDIR/backup.mbox $WORKDIR/backups/backup_$date.mbox ;
else [ $OUT -eq 1 ]
exit 1
fi ## Cleanup older than 3 days backups
find $WORKDIR/backups/* -mtime +3 -exec rm ;
cd $WORKDIR && rm -rf oldmail-* ;

This script will:

1. Run getmail using the getmailrc config file you previously worked on.
2. If the above command will be successful, it ll create a backups dir into $HOME/.getmail and move the latest Mbox file there appending a date and time to its name. (by doing this we are sure next getmail run will happen on an empty backup.mbox file, thus it will just contain the latest content from your mailbox)
3. It ll re-create a backup.mbox file on $HOME/.getmail to avoid the next getmail run to fail.
4. In the end, it ll clean up older than 3 days backups to avoid a too crowded backups folder. (it removes the oldmail file as well since it is useless in our case)

In the end set up a cronjob that will run the above script and generate the backups for you every one hour:

0 * * * * $HOME/.getmail/getmail_run.sh > /dev/null

Feel free to let me know if you ve encountered any issue while following the above HowTo. Enjoy! * /usr/share/getmail4/getmailcore/_retrieverbases.py on line 901. ** More documentation about the getmailrc file and syntax can be found on getmail s documentation page.

I'd like to make pyroman IPv6 capable. That is actually the one big thing before calling it a version "1.0".I must admit that I havn't been very active on Pyroman (or Debian in general) the last years. This goes even so far as that "pyroman" was considered "abandoned" by Fedora or so. It is not; I use it on all my servers. It's still in use at the network I developed it for (after all there is not that much benefit for a workstation setup, where a 10 line iptables script will do the job just perfectly.).Anyway, I'd like to get IPv6 support into pyroman, but there is one big issue here: I don't have any machine using IPv6, so I havn't used ip6tables myself yet, so I don't know about all the magic involved ...So if you use IPv6, it would be very cool if someone would jump in to get full IPv6 support into pyroman. Madduck had already done some preliminary stuff, but I didn't get around to have a look at the integration or completeness yet.The '--no-act' and '--print' modes of pyroman should even allow development without any IPv6 support or root permissions in the system.Other things remaining on my pyroman wishlist:

• Fully automatic iptables firewall visualization
• Keeping traffic counters over firewall reloads
• Configuration UI
• A fancy 'arsonist' icon and a web page design

Keith and I have been pretty quiet about TeleMetrum for a while... but that doesn't mean we've been idle! In recent weeks, I've built up several more flight units and two more ground station boards, as noted in my production log. We're both trusting rockets solely to our boards and Keith's firmware at this point. In fact, we've accumulated a significant number of succesful flights, including a cool drag-race between 4" airframes at NCR Oktoberfest where we both put brand-new, nearly identical rockets fully at risk flying only TeleMetrum boards, and a flight by Keith the same weekend on a full-K Loki K350W moon-burner in which he set a new personal altitude record! I've also flown a board with 100-g accelerometer installed successfully in a flight that peaked at 52.8 g! We're now hard at work on a "next version" of the hardware, incorporating everything we've learned so far. There are a number of significant changes planned:

• Fully integrated, on-board GPS receiver and patch antenna, with support for off-board amplified antennas when airframe geometry or materials demand it.
• A change in the design of the circuit for firing e-matches to ignite ejection charges that will improve mechanical reliability, plus explicit support for using a separate pyro battery if desired.
• Inclusion of a "companion board interface" that we envision using for a pyro channel expansion board to support staging and air starts, among other things.
• Dramatic increase in the capacity of the on-board data logging memory.
• Changes in connector series to eliminate our dependency on expensive crimping tools for making cables.

To make all this fit, I'm stretching the board an extra 1/4 inch to a total outline of 1 by 2.75 inches. We're also moving all the connectors, the GPS patch antenna, and the beeper to the "back side" of the PC board. This is a win on several levels... it will allow us to have silk-screen labels for the connectors, will help protect the baro sensor from sunlight and the various surface mount parts from physical damage during rocket prep, and opens up more board surface area for component placement and routing on the "top side" of the board. In practice, this means that boards will be mounted on standoffs with all the active components facing "down" and the connectors facing "up." Before we'll be ready to build some of these, we need to get in some more flights to test the various changes we're making. In particular, the change in ejection charge circuit, and the GPS receiver chip and antenna choices we're now favoring. Unfortunately, Keith and I are now both into the time of year where launch opportunities come less frequently, even before we consider the weather. Meanwhile, Keith's firmware and ground station software are now doing nearly everything we've envisioned wanting from this project. It seems entirely likely that he'll be ready to declare "version 1.0" soon after we obtain and verify the functionality of our next version of the hardware... In the meantime, our friends at Woot have posted a really funny video combining material from a couple launches this summer of my 10-inch Goblin, on one of which we flew some of their screaming flying monkey dolls... Enjoy!

As mentioned earlier, I've uploaded a new Pyroman release to Debian. I've also updated the download at the download page on alioth for the non-Debian users.There is just one single user-visible change (under the hood I switched some Python API so you need python 2.4+ now, which was available in sarge already):This version has a new command line option, "--verification-cmd". This can be used to point to a script file to verify network connectivity. For example, you could try to send a ping to the next router, or you could ssh to another host, have it ssh back and touch a flag file in /tmp to signal success.Similar to the --safe option, it is meant as a safety feature to avoid locking yourself out of your system. But while --safe needs to be used interactively, this new command could be used when automatically activating new firewall rules, e.g. triggered by cfengine or some other configuration management. If the verification command does not succeed, the firewall rules will automatically be rolled back to the previous state.Note that I didn't get around to add IPv6 support yet. It would definitely be desirable to add ip6tables support, but I currently do not have any experience with IPv6, so I'm not sure I'd know how to do things right. Of course I'd welcome any patches.(In case you havn't read about pyroman yet - it's yet another tool to configure iptables firewalls. It puts a thin abstraction layer on top of iptables, but the main benefit is that it uses "iptables-restore" to quickly mass-set all the firewall rules - other tools tend to invoke several hundred iptables processes to achieve the same - and if any error occurs it will both give you a clear indication of which rule caused the error and rolling back your firewall to the previous state.)

Today, I uploaded a new version of my firewall configuration tool, pyroman, to Debian unstable.About 4 hours later I googled for "Pyroman Debian" and was surprised to find the upload notification in the top results. The first hour of this was probably spent with me doing some package function tests (I don't want to upload broken packages, after all), then the announcement was distributed to the -changes mailing list at Debian, which in turn was picked up by Google Groups.However that might be due to groups.google.com getting special treatment, though. For this resource, Google can actually trigger an update instead of having to have a spider frequently re-crawl all the contents.Still I find it pretty impressive to have such new data already in their main index. I was used to this e.g. for blog and news search, but not for regular web search.

Even though I ve dealt with IPv6 for almost a decade, have delivered presentations, and given multi-day courses on IPv6 security aspects, I ve never actually added IPv6 to my own server/home network infrastructure because it seemed that Linux and/or Debian just weren t ready for it. This seems to have changed (although there are still a number of problems) and in less than a day, I put a few of my machines online. In the following, I d like to share with you how I did it.

Kernel versions and stateful connection tracking Unfortunately, I have to start off with some bad news: even though Debian etch, our current stable release, which uses a Linux kernel version 2.6.18, speaks IPv6, I cannot recommend it for deployment, as the 2.6.18 kernel does not support proper stateful connection tracking for IPv6, and thus makes it impossible to firewall hosts in a sensible manner (I always add local packet filters to all my hosts, and if only to guard against the situation when a user installs a malicious programme to listen on a high port). Of course, it is possible to configure a packet filter statelessly in an acceptable manner once you know the use case, so do with this information what you wish; I prefer to stay general for now. For me, a remedy is almost around the corner: the 2.6.24 kernel seems to support stateful connection tracking for IPv6, and it s even available for etch as it will be included in the upcoming etch-and-a-half release. I simply ended up using the kernel packages pre-release, and so far have not had a problem with it. To do so, add the following line to your /etc/apt/sources.list, making sure to use a close archive mirror:

deb http://ftp.xx.debian.org/debian etch-proposed-updates main

I then just upgraded the system and pulled in all proposed updates. As that may have let in software that won t be part of etch-and-a-half, or even lenny, you may want to pin the archive and only upgrade the kernel packages, by adding to /etc/apt/preferences (replacing amd64 with your architecture):

Package: *
Pin: release a=proposed-updates
Pin-Priority: -1
Package: linux-image-2.6.24-etchnhalf.1-amd64
Pin: release a=proposed-updates
Pin-Priority: 600

Alternatively, you could use the 2.6.24 linux kernel packages on backports.org.

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a dom0 on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 dom0 is reported to work, however.

Configuring the packet filter The first thing I did was to configure the packet filter on each host appropriately. Unfortunately, this is harder than it should be, because to quote one of the netfilter developers when ip6tables was conceived, someone had a big bad brainfart : rather than adding IPv6 rules to your existing iptables ruleset, you have to create a new ruleset, duplicate all chains, networks, hosts, and individual rules, and maintain the two in parallel. Even though there are efforts of unification on the way, I speculate it ll take another couple of years until PF_INET6 will be fused into PF_INET and one will be able to do sensible cross-address-family packet filtering with Linux. Since I ve recently started to look (again) at pyroman, maybe the most logical way forward would be to extend it to write both, IPv4 and IPv6 rulesets from its knowledge about the hosts and networks you configured. Anyway, we want to get stuff working now! Thus, let s configure ourselves a packet filter. (Almost) all IPv6-related filtering must be configured via ip6tables (read on further down about IPv6 in IPv4 tunneling, the reason I said almost ). The following is a simple default ruleset to start with, which I put into /etc/network/ip6tables to load with ip6tables-restore:

*filter
:INPUT REJECT [0:0]
:FORWARD REJECT [0:0]
:OUTPUT ACCEPT [0:0]
:in-new - [0:0]
### INPUT chain
# allow all loopback traffic
-A INPUT -i lo -j ACCEPT
# RT0 processing is disabled since 2.6.20.9
#-A INPUT -m rt --rt-type 0 -j REJECT
# allow all ICMP traffic
-A INPUT -p icmpv6 -j ACCEPT
# packets belonging to an establish connection or related to one can pass
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# packets that are out-of-sequence are silently dropped
-A INPUT -m state --state INVALID -j DROP
# new connections unknown to the kernel are handled in a separate chain
-A INPUT -m state --state NEW -j in-new
# pass SYN packets for SSH
-A in-new -p tcp -m tcp --dport 22 --syn -j ACCEPT
# log everything else
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT6]: "
### OUTPUT chain
# RT0 processing is disabled since 2.6.20.9
#-A OUTPUT -m rt --rt-type 0 -j REJECT
# allow outgoing traffic, explicitly (despite chain policy)
-A OUTPUT -j ACCEPT
### FORWARD chain
# RT0 processing is disabled since 2.6.20.9
#-A FORWARD -m rt --rt-type 0 -j REJECT
# disallow forwarded traffic, explicitly (despite chain policy)
-A FORWARD -j REJECT
COMMIT

Note that this recipe is pretty much unusable on pre-2.6.20 kernels due to their broken implementation of stateful connection tracking. The ruleset should be fairly obvious, but you might wonder about my use of REJECT and allowing all ICMP after all, you ve heard for the past 30 years that ICMP is a bad hacker protocol , and Internet security is no domain for being nice to people, so to prevent any information disclosure, you should DROP connections, not let people know that they re simply not allowed. Well, to hell with all that! I don t see a single reason or attack vector that is foiled by DROP or disallowing ICMP. In fact, it s just security by obscurity, and might inconvenient at the same time. ICMP is also much more important with IPv6 than with IPv4 (it replaces ARP, for instance), and it s actually useful to be able to ping hosts, or get back informational messages on why something failed. Finally, rejecting traffic rather than dropping it doesn t suggest to a hacker that something s hidden here. Then there is RFC 4890, which almost made me puke. This document is part of the reason why I say: let s fix problems in the kernel, rather than shielding them with unreadable and unmanageable rulesets!

Getting connected If you already have an IPv6 address, you re basically ready to go, but may want to read further down on how to connect your local network to the IPv6 Internet as well. If you are searching for a provider, have a look at the list of providers with native IPv6 connectivity over at sixxs.net. If you are reading up to here, I assume you are connected to the Net with IPv4. There are two ways for you to move towards IPv6: 6to4 or by way of a tunnel provider. A Kiwi website explains how to setting up 6to4 connectivity, and thus I will concentrate only on the tunnel approach. Even though everyone can set up 6to4 in a breeze without any accounts or waiting, there are a number of security considerations, it s pretty ugly to debug (due in part to asymmetric routing), and makes your life unnecessarily difficult when all you have is a dynamic IP that changes from time to time. If you are stuck behind a NAT gateway, you cannot use 6to4 either. Thus, I prefer the tunnel approach. With the tunnel approach, IPv6 packets are wrapped up in IPv4 packets on your host, and sent to the IPv4 address of your tunnel provider, who has native IPv6 connectivity. The tunnel provider unwraps your packet and shoves the contained IPv6 packet onto the backbone. The IPv6 address you used as source address is routed to the tunnel provider, so any replies arrive at their machines, where they re again wrapped into IPv4 packets and sent to your (publicly-accessible) IPv4 address. Those IPv4 packets specify payload type 41 ( ipv6 ), which is why we need those -p ipv6 -j ACCEPT rules in the iptables ruleset. There are a few tunnel providers out there. I chose SixXS and have not regretted my choice. I shall thus assume that you do the same: sign up for an account right now, so that you have it by the time you finished reading this document! SixXS works on a credit system: tunnels and subnets cost credits, which you can accumulate by maintaining your tunnels properly. This ensures that everyone can play around, but to do more advanced stuff, you need to first display competence with the basic concepts. Your first step with SixXS will be to request a tunnel. SixXS offers three types of tunnels:

• static tunnels, for those with static IPs,
• heartbeat tunnels, for those with dynamic IPs, and
• AYIYA tunnels, for those behind NAT gateways.

Each of these tunnels have advantages and disadvantages, as everything does: the first two types of tunnels use IP protocol 41 packets to encapsulate the IPv6 packets. As such, there are security considerations involving the impersonation by spoofing, and all upstream firewalls must let protocol 41 pass. AYIYA addresses these problems by using signed packets, but that solution comes with extra computation overhead and smaller MTUs. I suggest to use the first type of tunnel that fits your situation. Debian s aiccu package can take care of heartbeat and AYIYA tunnels for you, and it can even set up static ones. During registration, you will also need to choose a PoP , which stands for Point of Presence . If your country only has a single PoP, that s the one you will end up using (unless you have a good reason for another one), but if there are more options, I strongly suggest that you go through the list of PoPs and select the one with the best roundtrip time and lowest latency from your location! Note that you must answer ping requests (ICMP echo-request) from the PoP you chose, or else the tunnel will not be created. Once your tunnel request gets approved, you ll get a /64 prefix, in which you only use two addresses: the PoP will configure the :1 address and you need to configure your host to use the :2 address on the tunnel interface. You ll also be told the IPv4 address of your PoP endpoint . Joey Hess taught me that aiccu can set up the interface for you, using the data it queries from the SixXS registration (TIC) server. I tried it, and it works. However, I prefer the pure ifupdown approach, as it makes things explicit and allows me to use the hooks for stuff like loading the packet filter. So in my /etc/network/interfaces, you can find:

auto sixxs
iface sixxs inet6 v4tunnel
  endpoint 194.1.163.40
  address 2001:41e0:ff00:3b::2
  netmask 64
  gateway 2001:41e0:ff00:3b::1
  ttl 64
  pre-up ip6tables-restore < /etc/network/ip6tables
  up ip link set mtu 1480 dev $IFACE
  up invoke-rc.d aiccu start
  down invoke-rc.d aiccu stop

Make sure to read about MTU values of the tunnel and adjust the 1480 value in the above to your tunnel settings and ISP connectivity. Also set ipv6_interface sixxs in /etc/aiccu.conf, if you are using aiccu, or else aiccu will bring up a duplicate/additional interface. If you tell it to use the same interface, it will actually execute all the same commands (which will fail), but won t report any errors. A future version will have a switch to prevent it from configuring the interface. Unfortunately, this will probably not work. The reason is that your regular IP packet filter (iptables, without the 6) doesn t let those encapsulating IPv4 packets pass, unless we tell it to; we probably want to do this early on in the chain, and also limit it to our tunnel peer, so:

iptables -I INPUT -p ipv6 -s 194.1.163.40/32 -j ACCEPT

For AYIYA, you need to open port 5072, either for UDP, TCP, or SCTP, depending on how you configured it. Also have a look at this FAQ entry on what a firewall needs to pass. If it still doesn t work, you have an upstream packet filter that needs some of those holes poked. Good luck. In most situations, the FORWARD chain does not get such a rule, since the tunnel terminates at the gateway, which routes to a native IPv6 network, or another tunnel. Allowing tunnels through a gateway is almost always a bad thing, as it would allow undetected and untraceable traffic from compromised boxes in the local network. The OUTPUT chain also does not need such a rule, if you have configured stateful filtering properly. Now bring up the interface and verify the connection:

# ifup sixxs
# ping6 -nc1 2001:41e0:ff00:3b::1
PING 2001:41e0:ff00:3b::1(2001:41e0:ff00:3b::1) 56 data bytes
64 bytes from 2001:41e0:ff00:3b::1: icmp_seq=1 ttl=64 time=74.0 ms
[...]
# ping6 -nc1 ipv6.aerasec.de
PING ipv6.aerasec.de(2001:a60:9002:1::184:1) 56 data bytes
64 bytes from 2001:a60:9002:1::184:1: icmp_seq=1 ttl=55 time=91.5 ms
[...]

Welcome to the Internet of the future!

Setting up an IPv6-capable gateway Your IPv6 connection works, but it s limited to a single address, and you do not get to specify the reverse DNS PTR record for it. Since the concept of NAT is mostly absent from IPv6 (thanks! thanks! thanks!), you will not be able to connect any other hosts to the IPv6 network. If your local network has a few hosts behind a gateway, you will need to request a subnet from SixXS and configure your gateway (which has the tunnel connection) appropriately. Don t worry, this is not really very difficult. First, request a subnet for your tunnel from your PoP via your SixXS homepage. Once approved, you will get a /48 prefix for your own use: 2^80 1.2 heptillion addresses which are yours to assign to every dust particle in your office or home, if you so desire. The way I set it up is to add the first of these addresses to your internal interface on the gateway, by adding the following two lines to the interface s stanza in /etc/network/interfaces; you will need the iproute package installed (which you should be using for everything network-related anyway):

up ip -6 addr add 2001:41e0:ff12::1/64 dev $IFACE
down ip -6 addr del 2001:41e0:ff12::1/64 dev $IFACE

Instead of bringing the interface down and up, just run ip -6 addr add 2001:41e0:ff12::1/64 dev eth0. Note the use of the /64 prefix instead of the /48 that got assigned, leaving only 20 pentillion addresses. Oh no! The reason for this is buried in the specs: basically, /48 is a site prefix, but individual networks should not be larger than /64, which is the prefix length of links in the IPv6 domain. Now is also a good time to enable IPv6 forwarding, e.g. like so:

# echo net.ipv6.conf.all.forwarding = 1 >> /etc/sysctl.conf
# sysctl -p /etc/sysctl.conf

Obviously, you will also need to change the policy on the ip6tables FORWARD chain. For now, let s just set it to accept. You should later create a proper ruleset, though!

# ip6tables -I FORWARD -j ACCEPT

Bringing IPv6 to your local network The final step is to spread the love to your local network. Refrain from selecting addresses from your subnet and assigning them to the local hosts, or wondering how to configure the DHCP server, because IPv6 does it differently: your gateway will advertise its routes (which includes a default route) to your network, and each host will pick an address based on its MAC address (unless it already has an EUI-64 address assigned. This all happens automagically, at least with current Debian and Windows machines. On the gateway, you need to install radvd and simply tell it which prefix to use on which interface. My /etc/radvd looks like this, and I won t explain it:

interface eth0
 
  AdvSendAdvert on;
  prefix 2001:41e0:ff12::/64
   
   ;
 ;

Note again how we advertise a /64 network rather than the /48 we own . You cannot advertise smaller networks if you want automatic configuration to work, and you should not use networks larger than /64 in any case. If 2^64 addresses are not enough for you, I trust you ll be able to figure out how to advertise another of your 65536 /64 prefixes in the /48 subnet to appropriate hosts. Restart radvd and run over to another host to witness how it automagically gets connected to the IPv6 network by scanning /var/log/kern.log and watching the output of ip -6 addr and ip -6 route. Try ping6ing from there! Find the dancing turtle! It should all work. If you don t like the automagic aspect of this, look into stateful configuration, using DHCPv6, as provided by dibbler-server and ?wide-dhcpv6-server.

Resolving names Take note of the IPv6 address of each host. There s a way to determine it given the host s MAC address, but this is easier (ipv6calc is also useful). You might want to let your local DNS server know by adding AAAA records in parallel to the existing A records, and possibly even adding PTR entries. If you re serious about IPv6, you can tell SixXS to delegate reverse lookups for the IPv6 addresses to your DNS servers, but you ought to refrain from polluting the DNS namespace. Note that bind9-host provides an improved host tool, which fetches all kinds of information about names, not just the one single information configured as default:

% host pulse.madduck.net
pulse.madduck.net has address 130.60.75.74
pulse.madduck.net has IPv6 address 2001:41e0:ff1a::1
pulse.madduck.net mail is handled by 99 b.mx.madduck.net.
pulse.madduck.net mail is handled by 10 a.mx.madduck.net.
% host 2001:41e0:ff1a::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.f.f.0.e.1.4.1.0.0.2.ip6.arpa
domain name pointer pulse.madduck.net.

Oh, and if you re really that curious about how IPv6 addresses are computed from MAC addresses, read RFC 2464. Basically, given a prefix 2001:41e0:ff1a:: and a MAC address aa:bb:cc:dd:ee:ff, the resulting IPv6 address is obtained by:

1. inserting ff:fe into the middle of the MAC address to yield aa:bb:cc:ff:fe:dd:ee:ff;
2. flipping the second lowest bit of the first octet to yield a8:bb:cc:ff:fe:dd:ee:ff;
3. removing the odd colons to yield a8bb:ccff:fedd:eeff, the EUI-64;
4. concatenating the prefix and this result to get 2001:41e0:ff1a::a8bb:ccff:fedd:eeff.

If you find your (Windows) IPv6 addresses changing all the time, you might be faced by privacy features .

Remaining issues Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what s going on.

Mapping names to laptops Laptops generally have two interfaces, one with a cable, and the other wireless. Both of these interfaces will have separate MAC addresses, and by extension, the laptop will have different IPv6 addresses depending on how it is connected to the local network. I want to be able to connect to laptops without knowing the medium they use to connect to the network. Unfortunately, there seems to be no feasible way. The solutions I see are:

• override the MAC address of one interface with that of the other, which is going to cause bgi problems in the case when the laptop (accidentally) gets connected to the same network twice;
• add both IPv6 addresses as AAAA records to the laptop s DNS name, which will cause random delays when connecting as the resolver may return the currently inactive address first;
• set up mobile IPv6, e.g. by following this Mobile IPv6 how-to, which would allow accessing the laptop uniformly, no matter where in the world it is. Unfortunately, Debian s support for Mobile IPv6 is severly lacking at time of writing. Also, Yves-Alexis Perez notes that this how-to is horribly outdated and promised to tend to it Real Soon Now .

The second solution works for me for now, but I am interested in the third. In response to this document, Andreas Henriksson has suggested the replace the stateless configuration (radvd) with stateful configuration, using DHCPv6. I have yet to investigate this option. Jeroen Massar suggests to unite cable and wireless into a bridged interface, which seems like a very good idea.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on #ipv6/irc.freenode.org for their help over the past few weeks, and all those who fed back comments in response to this document!

Here is something I wrote some while ago, hope this will be useful for some World of Warcraft p(l)ayers. Has no other relation to Linux or Debian, except it works on it flawlessly. Also note that 2.3.2 patch went live last week. It is not a secret anymore that mages of all talent specs will be getting a present when patch 2.3.2 hits the live realms - the Ice Block will be available from any friendly mage trainer for a nominal fee. Currently this spell requires a whopping 21 point investment into the Frost talent tree. With patch 2.3.2 Ice Block will become trainable to all mages, Ice Barrier will take it’s place in the talent tree and a new awesome talent - Icy Veins will take the place of the Ice Barrier, so that even frost mages have a new toy to gain in this 2.3.2 mage winterly fiesta. While there is a significant proportion of mages that are frost for PVP or grinding survival purposes, a large proportion of mage population have never used Ice Block or haven’t used it for a while. For that reason, the rest of this article (after the break) will explore all the great uses of Ice Block, that all of you can look forward when patch 2.3.2 hits the live realms (or sooner, if this article convinces you to re-spec frost :)). So, what does the Ice Block do? When you cast the Ice Block, it purges you from all debuffs and releases you from all snares, you get frozen solid into a large block of ice (same look as hunter’s ice trap) and for 10 seconds you are immune to all damage, but unable to do anything - no moving, casting anything, no bandages, nothing. Getting rid of: Ice Block is a buff, so you can get out of the Ice Block by right-clicking it off at any time. Another way for keyboard-addicted mages is to press Ice Block keybinding button again (after the global cooldown is done). Enemy shamans can purge it off you and priests can mass dispel your Ice Block in PVP. Cooldown: the Ice Block is on 5 minute cooldown, which can be ended early using the Cold Snap talent from the mage frost tree. To prevent mages casting two ice blocks back to back by using the Cold Snap, Blizzard added the Hypothermia debuff (in 2.1) that prevents you from casting the Ice Block 30 seconds after the last cast. The main use of Ice Block is to survive pulling aggro in groups. While we all know that “good mages don’t draw aggro”, experienced players can easily show situations when drawing aggro is not mages fault and surviving that can be the difference between a wipe and a win. When Ice Block is used, your threat is NOT reduced, so you need to stay inside the Ice Block at least until you are under 130% of the tanks threat. After you Ice Block, the mob will run to the next person on the threat list. If your tank is dead, Ice Block will send the mob to another DPS or healer giving you a couple seconds to nuke it when it will be running back to you again. I have seen a few bosses loose their last 2-3% of health running between mages with Ice Block and hunters with Feign Death after a unfortunate death of the main tank. Ice Block is a great way to get rid of almost all debuffs that exist in the game: warlock DoTs, stuns, snares, polymorph, mind control … Even boss debuffs go away in a snap - Garrote from Moroes, Demonic Chains from Illhoof and many more deadly debuffs are no threat to a mage with an Ice Block ready. Ice Block can be used as an alternative to Slow Fall if you’re out of Light Feathers. Just do not cast it too high in the air - if the 10 seconds tick by and you haven’t hit the land yet .. you could as well kiss 10% of your durability goodbye. When solo grinding there is noone to draw aggro from you, so the mobs will continue to beat on your personal icy sculpture, however during that time your Water Elemental or other battle pets could be dishing some damage, your cooldowns will tick down and also you will also regenerate some mana inside the Ice Block. The Ice Block could thus make the difference between your death and Frost Nova+Blink+Blizzard and their death. Have you had some fun experience with Ice Block? Leave a comment so that others could repeat it too!

Thursday evening, I joined the inhabitants of the twin town of Valga-Valka, sitting smack on the Estonian-Latvian border, to celebrate their entry into the Schengen treaty. Ever since I first crossed the border there on a roadtrip from Tallinn to Fallingbostel, in year 2001, I knew I would have to return and, sure enough, I briefly passed through during last summer with an Estonian friend, on our way to an acquaintance's birthday party. Still, that told me nothing of the town's life and left me wanting for more. Upon hearing that year 2004 EU accession countries would join Schengen in December 2007, I immediately promised myself to show up and join the crowd. As it turns out, I missed Aleks Tapin of the All About Latvia blog by very little, having I caught his last-minute e-mail the next afternoon. Aleks blogged a great article depicting the Latvian side of life and providing some background info on the town, if you're curious. I arrived late-evening on Thursday via the Tallinn-Viljandi-Valga bus and checked into my hotel, then proceeded to checkpoint Valga II around 23:30, with the intention of grabbing a drink on the Latvian side and returning just before midnight for the celebrations. Hardly anyone was in sight, except for Latvian officer abana who was completing the inspection of a Russian car with three noisy passengers. Upon presenting her with my passport, officer abana cheerfully lead me to the office and slid my passport through a slot to officer Bukss, who was visibly surprised to have any tourist show up on the last day of his job to get their passport stamped. Upon explaining to him the reasons for my presence, he pointed me to a nearby bar where I could have a drink, visibly amused by the situation. I spent the next few minutes in a local casino in the company of three hilarious Latvian truck drivers, Zintars and Aivars, two Latvians with limited English language skills and Yuri, an ethnic Russian living in Ireland who was born stateless on the Latvian side of the town and who later acquired Estonian citizenship by claiming ancestral land on the Estonian side. Upon returning to the border, just minutes before midnight, I found myself in the middle of a huge crowd of villagers, police officers, border guards and politicians from both countries - barely getting noticed by anyone. I handed my passport to an Estonian border guard who emotionally commented to a civilian friend of his nearby that, "Wow! That was the last one!", handing me my passport back just as the midnight bells rang and the mayor of the Estonian side started his speech amidst pyrotechnics lining the road. I then had a chance to chat with the Estonian mayor, who promptly handed me a bilingual certificate, signed by the mayors of both towns, attesting that I was the first to cross the open border, while introducing me to his two young daughters with whom he was about to take a stroll on the Latvian side. The next morning, an even bigger and more symbolic event took place: the demolition of the fence that had been cutting the S prus/Rai a street in half. You can see a picture of what the street looked like before on Aleks' blog article [edit: or on Jens-Olaf's blog article]. After the fence was removed, it instead looked like this: The crowd then proceeded to checkpoint Valga III, where a stage had been setup for the politicians to make their speeches. An interesting fact is that, because of the way the border was drawn, along a creek leading to Pedeli river, an Estonian main road was technically on the Latvian border and thus aptly named "Raja" (border) street. The Estonian mayor commented in his speech that the the brand new supermarket standing behind us was also technically on borderland and could not have possibly been built earlier, weren't it for the Schengen treaty matter-of-factedly eliminating borders between participating EU countries. The speeches were closed by a youth group whose choreography featured six break-dancing boys, dressed as Estonian and Latvian border guards and as border posts. The choreography ended with the teenage border guards carrying away the human posts on their shoulders, just as a choir of young girls replaced them with songs in either languages. Before catching my bus back to Tallinn, I dropped by the Valga tourist info, only to face a nervous-looking Kapo officer in plain clothes. Upon mumbling something about the tourist info and wanting to grab maps, I noticed that a press conference was taking place behind. As he finally let me pass to the tourist info side of the building, a familiar voice said to me, "Hey! Weren't you at our place last summer with Martin Ranna?" Yup, the wife of the acquaintance whose birthday party I had attended last summer is working there and greeted with me refreshments and munchies she had cooked in prevision for the presidential visit! As was my luck, she had one of the commemorative plaques that had been given to the politicians at Valga III on hand: I was glad to see the town becoming one again, even though it is ethnically divided. There are already signs of people on both sides learning one another's languages and shopping on either side of town, not to mention plans of merging the municipal bus operations of the Estonian and Latvian halves of the town, so I'm sure that they'll get there in due course. For me, Schengen brought a much more practical and quite welcome change: the end of messy border crossing stamps that were rapidly filling my almost new passport, every time I visited the head office of our company in Tallinn. While Estonian border guards mostly stamp passports in an orderly fashion, being careful to fit exactly 8 stamps in a single page and to put entry and exit stamps side-by-side, Finnish border guards apparently are incapable of doing so, instead systematically wasting pages by either stamping sloppily in a way that makes it impossible for more than 4 stamps to appear on a given page or by flipping to a brand new page, every time I had to cross the border. In case anyone ever wondered why I'm currently representing Estonian interests abroad, despite living in Finland, this example is one of the many reasons: Finnish authorities routinely display arrogant carelessness towards the population and doubly so towards immigrants. It amounts to an accumulation of idiocy that has costly consequences on people's lives. For some, it's about being denied the public institutions' support when they need it the most and their life forever going downhill thereafter. For me, it has been about countless missed opportunities (jobs, love affairs, travel plans), plus very costly passport and residence permit renewals. Given this, I simply don't see myself ever representing Finnish interests ever again. Faith no more. Besides, the Estonians are fun and easy-going people. Siski ma m tlen, kas ma peaksen n d Eestisse kolima v i?

… is that more than one are likely to have the same crazy ideas. When I started to play with xulrunner, which according to my oldest post in the xulrunner category would be near 2 years ago, I had this crazy idea (and here, when I say crazy, I almost think dumb) that it would be neat to have a window manager based on libxul, being able to display both “native” windows and XUL or HTML windows. Indeed, it would be neat, as in web-2.0-hype or i-can-use-gmail-directly. But that would be so much impossible to secure, and introduce so many different new ways to compromise users… Guess what… It now exists. Update: Waw, the GUADEC keynote slides are really full of crap. My favorite ones are about “The Fox” : Good engineering practices and Small, extensible core.

I've written a small parser for iptables rules in Python, and made it output GraphVis data. Byte counters are translated to line width, packet counters to line color. Dashed lines didn't receive any data so far. This is the result for my laptop's tiny firewall setup (generated by Pyroman; the double accept/drop/reject rules are mostly for cosmetic purposes, and counting data and packet totals. However the reject rule also does a 'cleaner' reject for TCP connections) I've ran it on a much larger firewall (~100 chains, ~600 rules; a multi-homed firewall at our university), but it becomes to messy with the dotty layout algorithm. The firewall chains generated by pyroman are pretty flat; it generates one chain per client-server combination, the INPUT etc. chains are filled with source/destination filters, the services are filtered in the second level then. Also most of the traffic is handled by connection tracking, so it boils down to having one big accept line, with little going on beyond that. So the visualization turned out to be only of partial interest (at least for Pyroman-generated firewalls. It could be useful if someone actually nests chains more levels deep). Still there is some interesting stuff I might be going to try with the iptables-save parser I've written:

• pyroman could reload the firewall, keeping traffic counters where possible
• based on traffic counters for hosts and services, it could reorder entries in the firewall to optimize the firewall slightly (in the pyroman model, hosts and services can be reordered to a certain extend; I'm aware that this is not true for generic iptables rules. It might however be still helpful for some users to get suggestions on how to order their rules. It's also unlikely this will have a large performance impact in general, unless you have one really heavily used service and didn't place it first on your own...)

[P.S. Anyone aware of a GTK/Gnome application or library for visualizing graphs?]

I've been added to Planet GNOME (thanks jdub!), and this post is just to say hello! I havn't been a large GNOME contributor so far (I was the Debian maintainer for Galeon some years ago, thats about it), but I recently started a small DBus related project (for exploring the DBus APIs of programs), dbus-inspector, which is now hosted in the GNOME subversion repository. Other GNOME-related projects I'm thinking of:

• DBus hook, an application that allows you to easily setup ECA rules (event-condition-action) for DBus signals. E.g. to start your music synchronization tool when you plug in your mp3 player, whatever, in a rather generic way. Mount your network file server when you connect to your home wireless network, etc. - preferrably in an easy to understand way
• MP3val GUI, right now a tiny PyGTK wrapper around the MP3 validation and repair tool mp3val (you can't imagine how many MP3's are broken in one way or another, fortunately most errors are ignored by most players or only affect e.g. seeking) could use some extended functionality.
• Pyroman, a firewall configuration tool with some nice capabilities (rollback on error, debugging, very fast and efficient, Python or XML configuration files) could use an easy to use UI. It doesn't expose you to all the complexity of iptables, but instead lets you work in a "client, server, service" way of configuring the firewall, generating a somewhat sane layout of tables automatically.
• Flow analysis and visualization of iptables rules

I'd like to say thank you for all the great work you did. Having been a Galeon power user, I'm by now quite convinced of the "keep it simple" approach, and I have the impression that not having so many options means that I get more work done (since I don't waste time playing around with infinite options). Thanks for that. And for providing me with a pretty and unobtrusive work environment for the last 8 years or so.

An email forwarded to me by a neighbour about the Rubbish Or Resource consultation says:

"Did you know that the Councils in the area that used to be Avon want to know what you think about how they should spend our money to deal with our rubbish? They've got together and produced a plan for the West of England and want your views by Friday March 23rd. North Somerset Friends of the Earth think this consultation is rubbish because it's been badly publicised (did you know about it?) and it seems the Councils have already made up their minds. Their plan accepts that the only way to reduce the amount of waste going to landfill is to dispose of it by burning it or digesting it biologically rather then by promoting the "3Rs", Reduce, Reuse, Recycle. Their plan describes seven types of treatment facility and then prioritises them with pyrolysis/gasification and burning (sorry "Energy from Waste") as their favourites. Call that choice??!!"

Read more at GoWeston

I was reading the brochure about the BMW 530i Touring (which seems to be the BMW name for what is known as a "Station Wagon" in Australia or an "Estate" in Europe). I looked at the brochure on the "Touring" because I am interested in a Station-Wagon - the Sedan version of the 5 series is almost the same in every way other than size and shape.

Here are some of the interesting features:
Adaptive headlights, they turn in to a corner when the car is cornering (showing where you are about to go instead of showing you the scenery off the road) and the high-beam switches off when an oncoming vehicle is detected.

Head-up display for speed, navigation, and other driver-relevant information.

Park distance control (PDC). Gives audio and visual alerts when you are about to hit something at low speed.

Eight air-bags of which only the necessary ones will inflate in a collision, and the inflation power will be determined by the severity of the collision.

Dynamic stability control (DSC), traction control, corner brake control, and more. Described as "all of the known features of DSC".

Seat-belt pre-tensioners in the rear and pyro-technic tensioners for front seat belts.

Rain sensor that turns on headlights, and optional head-light washers.

According to it's brochure the 7 series has bumpers that regenerate their original shape in collisions of speeds up to 6Km/h and a tire defect indicator. Apart from that there doesn't appear to be much benefit over the 5 series apart from more luxury features.

To get the PDF files from BMW Australia (without following my links which BMW will probably break soon) you have to fill in a form with "contact details". To enter that form you need a browser that works with their javascript (which means not Konqueror) so that you can enter your postcode and be prompted with a list of suburbs that match the post-code. The second-last page of that process allows you to download PDF files and it seems to indicate that your data will not be stored if you don't continue past the stage where you download the PDF files. It would be good if BMW could get smart and make their PDF files as easy to download as Mercedes does.

In terms of safety features it seems that the 7 series offers little over the 5 series. By comparing the brochures it seems to me that the Mercedes S series (as described in my previous blog post) has many more safety features than any BMW. Assuming that the BMW documents are accurate they don't seem to compare well with the Mercedes S class. From a quick search on drive.com.au (the best web site for buying used cars in Australia) it seems that the Mercedes keeps it's value better than the BMW - other people apparently share my opinion of the relative merits of the cars.

In future posts I'll summarise the features of some other cars that I consider interesting.